[レポート] Well-Architected Bootcampに参加してきたよ

杉金晋

2021.10.04

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

みなさんこんにちは、杉金です。

AWSが主催するWell-Architected Bootcampに参加してきました。今回はその体験レポートと、おまけとしてWell-Architected Frameworkのおさらいをします。Well-Architected Frameworkってとっつきにくいんだよなぁぁって思ってる方の参考になればと思います。

昨年の参加レポートもございますので、こちらもぜひご参考にしてください。

[レポート] Well-Architected Bootcampに参加してきました
https://dev.classmethod.jp/articles/well-architected-bootcamp-20200716/

Well-Architected Bootcampの目的

AWSを活用したシステム設計/構築/運用経験のある参加者が更に最適なシステムに進化させられるようWell-Architected Frameworkとは何かを知る
Well-Architected Partner Programについて知る
Well-Architected Frameworkを使ったレビューを体験する

タイムテーブル

時間	内容
10:00~12:00	Well-Architected Framework、Well-Architected Partner Programの説明
12:00-13:00	お昼休憩、事前資料の読み込み
13:00-18:00	チームディスカッション（Well-Architected Frameworkの柱ごとに実施）

体験レポート

このブートキャンプは丸１日かけて行われます。まずは午前中にWell-Architected Frameworkのおさらい、続いてWell-Architected Partner Programの説明でした。Partner Programは本記事冒頭にリンクを貼ってますのでそちらをご確認ください。メインとなるのは午後から始まるチームディスカッションです。あるシナリオが事前資料として渡され、それをもとにAWSのソリューションアーキテクトの方がお客様を演じて実際のWell-Architected Frameworkレビューを体験します。参加者は複数のチームに分かれて、チームにつき1,2名のAWS SAの方がついてチームごとにレビューを行い、レビューで得られた現状の分析(As-Is)と有るべき姿(To-Be)をチームごとに発表します。1つのシナリオをWell-Architected Frameworkの5つの柱（運用、セキュリティ、信頼性、パフォーマンス、コスト）ごとにレビューと発表を繰り返していきます。

実際に体験してこれは手強いと感じました。理由は以下です。

AWS SAの方が演じるお客様のすっとぼけ具合がやばい
レビューのための質問が難しい
時間が足りない

それぞれの理由について解説していきます。まず1点目ですが、レビューのために質問を投げかけると、なんとなくとか、よく分かってないとか、とりあえず前と同じにしたとか欲しい答えがすぐには出てきません。また、あるべき姿について提案しても質問が返ってきてその返答をしていると時間が無慈悲に消費されます。Well-Architected Frameworkなんて、ベストプラクティスに従っているかチェックしていけばいいでしょ、ぐらいに思っていた私は愚かでした。このあたりは2点目にも繋がってきますが、分からないお客さんに対して、分かるように質問を投げかける難しさを知りました。イメージのつかない方のために、ひとつ例を挙げてみますが、運用優秀性の項目(OPS1)の質問とベストプラクティスは次のような内容になっています。

〜質問〜

優先順位はどのように決定すればよいですか？

〜ベストプラクティス〜

外部顧客のニーズを評価する
内部顧客のニーズを評価する
ガバナンス要件を評価する
コンプライアンス要件を評価する
脅威の状況を評価する
トレードオフを評価する

引用元：https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/a-organization.html

これらをそのまま丸投げしても期待通りの返事は返ってきません。あなたならどのようにこの質問とベストプラクティスを伝えますか。噛み砕いて伝えたり、SLAやKPIなどの指標に言い換える必要が出てきます。更に加えると「特に要件がないです」という答えが返ってきてもそれを鵜呑みにせずに角度を変えて形にしていく必要があります。このあたりのやりとりは実務でも似たような経験がありますので、リアルだなと思いました。

噛み砕いた説明をしたり、詳細を解説したり補足すると時間がかかります。それが3点目で、時間内にすべてのベストプラクティスをチェックする時間は足りませんでした。このブートキャンプの時間配分が悪いのかと最初は思ったのですが、実際のお客さんとのレビュー会を想定しても時間は限られていますので、効率よく粘り強く進めていく必要があると感じました。このあたりはWell-Architected Toolを活用してレポートを残しておけば、メモなどを見て２回目以降はスムーズに進められそうです。

これらの手強さに加えて、チームディスカッション系であるあるなのが、初対面同士で組んだチームでの振る舞い方に悩むことです。自身がリードして自分のやりやすい進め方にするのが一番楽ですが、色んな方の意見も聞きたいしチャンスも平等に分けたいです。最初は探り合いでなかなかスムーズには進めなかったのですが、回を重ねるごとに改善していきました。このあたりは、プチチームビルディング的な感じで楽しめました。関係者(ステークホルダー)との関係性を築くというのも得られた学びです。

このBootCampを一通り終えた感想としては、レビューの手強さはあるものの、議論することで不確かなものを明確にしていく意義を感じました。他チームの発表を聞いて異なる観点の気づきがあったり、参加者同士の実際の現場はどうか？みたいな話もあって得るものは多かったのですが、何よりの成果だったのがフレームワークのレビュー経験が不足しているなと心の底から実感できたことです。

おまけ：Well-Architected Frameworkおさらい

ここからはおまけです。Well-Architected Frameworkに対して苦手意識をお持ちの方はいるかと思います。Frameworkのドキュメント構造やツール画面を軽く紹介しますので、雰囲気を掴んで少しでも苦手意識解消に繋げられればと思います。

Well-Architected Frameworkとは

5つの柱からなる、AWS上のワークロードを設計および実行するための主要な概念、設計原則、アーキテクチャのベストプラクティス集です。

Well-Architected Framework ドキュメントリンク
https://aws.amazon.com/jp/architecture/well-architected/

柱って呼び方かっこいいよね

ドキュメント構造

ドキュメント構造は下図のようになっており、質問に対してベストプラクティスに沿っているかをチェックしていきます。

全てのベストプラクティスに沿う必要はない

必ずしもベストプラクティス全てに従う必要はありません。ビジネス的な判断で従わないものも当然あります。

Well-Architected Framework レンズ

レンズと呼ばれる専門分野ごとフレームワークが存在しており、執筆時点で9つのレンズあります。

Serverless
HPC
IoT
Machine Learning
Analytics
Financial Services Industry
SaaS
FTR(Foundation Technical Review)
Management and Governance

Well-Architected Frameworkレンズについて
https://aws.amazon.com/jp/architecture/well-architected/

AWSコンソールからWell-Architectedレビューができるのよ

AWS Well-Architected Toolを使用することでAWSコンソール上からチェックとレポート作成ができます。利用に追加料金はかかりませんので、試しに使ってみましょう。

1.AWSコンソールからアクセス

2.「ワークロードの定義」をクリック

3.プロパティを埋めていきます

ワークロードの名前、説明、レビュー所有者

環境は本番稼働中か本番稼働前か選べます。リージョンや領域、AWSアカウントを記載してレビュー対象を定義します。

アーキテクチャ設計図などのURLを記載できます。また、業種を設定できます。

4.レンズの選択

使用するレンズを選択できます。現時点で選べるのは4つで基本となるWell-Architected Frameworkのチェックは既についています。

5.ワークロード一覧

ワークロードを作成するとワークロード一覧に表示されます。

名前のリンクをクリックすると詳細が表示され、「レビューを続ける」ボタンからレビューを開始できます。

6.レビュー開始

レビューを開始すると質問とベストプラクティスのチェック項目が表示されます。各ベストプラクティスの内容が不明な場合はチェック横にある「情報」から詳細を確認できます。

7.メモを残せる

チェックを進めていくと画面下部にメモ欄がありますので、なぜチェックをつけなかったか等のメモを残しておくと、後から見直すときに役立ちます。

8.レビューを終えて

レビューを終えるとワークロード詳細画面から状況を確認できます。回答状況とチェックできなかった部分についてリスクとして表示されます。（高リスク、中リスク）また、マイルストーンとして残すことでき、レビュー1回目、2回目等に分けて、どのような経過で改善していったかも残せます。

リスクの詳細を確認すると、推奨される改善項目が記載されますので参考にするとよいでしょう。

Toolの使い方は大体このような感じです。まずはざっくり使うというところで、改善策の優先順位やレポート共有など割愛しましたが、そのあたり気になる方は記事最後の参考情報をご覧ください。

最後に

フレームワークはAWSの資格勉強で散々目を通してきたつもりでしたが、フレームワークの内容を骨身に浸透させるには設問やベストプラクティスを自分の言葉に置き換えて読み込む必要があるなと感じました。その一方で、Well-Architected Toolによって気軽にチェックできるのは便利ですので、回数重ねて慣れさせるのも大事です。Well-Architectedレビューに対する経験不足を感じるからこそ、Well-Architected Frameworkを積極的に活用すべきですね。このようなキッカケを与えてくださったBootCampに感謝です。